The advent of IEEE 802.11n wireless local area communication networks (WLAN), and in the near future gigabit WLAN networks, will require that older existing centralized switching architecture will need to be replaced with controllers and “thin” WiFi access ports having a new distributed architecture where access points (APs) are only managed by controllers. In this new architecture, the APs are configured to handle traffic themselves (bridging/routing of wireless-to-wired communications and vice versa), which is better suited for scaling to IEEE 802.11n with its higher throughputs as it will remove the bottleneck of controllers in central switching.
However, this new architecture poses new challenges when it comes to firewalling user traffic at different APs and controllers, particularly when a wireless client is roaming. Specifically, in case of tunneled-bridging mode for a WLAN, the user traffic from the wireless-to-wired network is statefully firewalled at both the AP and the controller. In this case, migrating a stateful firewall for the AP and controller, while a wireless client is roaming, without dropping the communication session becomes problematic.
As is known in the art, a firewall can be configured as either stateless or stateful. Stateless firewalls observe data traffic, and block packets based on source and destination addresses or other parameters. Stateless firewalls are not aware of traffic patterns or data flows. A stateless firewall uses simple rules to test packets and has no regard as to whether a source of the packets can be trusted. In contrast, stateful firewalls observe data traffic streams from source to destination. They are aware of traffic patterns or data flows and can implement various security functions including tunnels and encryption. A stateful firewall provides a level of consideration as to whether a source of the packets can be trusted.
In a system deployment where all controllers and APs are physically co-located on the same virtual local area network (VLAN), it is imperative that tunneled WLAN traffic is effectively load balanced across all available controllers in the deployment. Accordingly, when wireless mobile clients roam from one AP to another, firewall flow (or firewall-session) migration is presently provided from the old AP to the new AP to make sure that any communication sessions do not break during the roam. These firewall flows are migrated only between APs (i.e. firewall flows are not migrated to a controller that is bridging tunneled WLAN traffic from the wireless-to-wired communication network). At present, this is not an issue because there can only be one controller (typically an extended VLAN switch) that handles tunneled WLAN traffic bridged between the wireless-to-wired communication network, and these have always been stateful flows.
However, when traffic is load-balanced across multiple controllers, if a wireless client roams from a first AP that is tunneling WLAN traffic to a first controller, to a second AP that is tunneling WLAN traffic to a second controller, firewall flows will have to be migrated to the second controller as well. In addition, if there is a communication session between two mobile wireless clients connected to two different APs controlled by two different controllers, and the wireless clients both roam at the same time in reverse directions, then each AP will try to migrate flows to the other AP and the two controllers in between. So all in all flows have to be migrated to two APs and two controllers to make sure the communication sessions do not drop.
In another example, if two mobile wireless clients connected to the same AP roam away from the AP to two different APs, then the old AP will need to migrate flows of each wireless client to one new AP and two controllers. In total each flow related to the conversation between the two wireless clients will be migrated to six devices, ((one new AP and two controllers)*2 (number of clients roaming)). This makes things extremely complicated and greatly increases the probability of connections breaking during a client roam. Hence a simpler and more intuitive solution is necessary.
Any delay in migrating firewall flows can cause serious trouble in mobile clients if traffic cannot pass through network devices because of the absence of firewall flows. For example, SIP calls would suffer the most, followed by TCP connections—both of these types of connections can break, which leads to a bad user experience. Network deployment issues have already been encountered with the current migration to only two APs. Therefore, it is envisioned that the migration to four network devices is most likely going to make things worse.
Accordingly, there is a need for a new technique for firewalling in distributed networks, and in particular for traffic is already statefully firewalled at the edge of the network. It would also be of benefit if the new technique could make better decisions when handling tunneled WLAN traffic from network devices when mobile clients roam.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.